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(54) Method for reserving resources 



(57) A method for managing resources in a compu- 
ter system. 

According to one embodiment of the invention; a re- 
source manager receives a first request of a first oper- 
ation. The first request identifies a first resource and 
specifies an amount of the first resource needed to ex- 
ecute the first operation. In response, a resource man- 



ager determines if the amount of the first resource re- 
quested by the first request is available to be reserved. 
In response to the amount of the first resource request- 
ed by the first request being available to be reserved, 
the resource manager reserves the amount of the first 
resource requested by the first request in advance of 
allocating the first resource to the first operation. 
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Description 

FIELD OF THE INVENTION 

The present invention relates to computer systems, 
and, in particular, to reserving and managing computer 
system resources. 

BACKGROUND OF THE INVENTION 

In computing environments such as embedded sys- 
tems, set-top boxes, or general purpose computers 
where resources (e.g. memory) are limited, software is 
developed to accommodate the uncertainty of whether 
resources needed to complete an operation will be avail- 
able. 

For general purpose computers, well written soft- 
ware requests resources as they become needed and 
verifies that the requested resources were actually pro- 
vided. If it is determined that a resources was not pro- 
vided, the operation being performed is aborted part- 
way through, and any resources allocated in earlier 
stages of the operation are returned to the system. 

In a system with scarce resources, however, this 
approach does not perform well. For example, if there 
are only enough resources available for one operation 
to execute until completion, but the system begins two 
operations, both operations may fail halfway through. 

Some systems attempt to solve this problem by 
dedicating pools of resources for specific operations. 
This approach also has problems. 

Consider the example that we have two operations, 
A and B. Each operation is only allocated 1 00 bytes of 
memory. Further consider the case where operation A 
is not using its 100 bytes of memory and B needs 150 
bytes of memory. Even though the 200 bytes of memory 
are available in the system, operation B cannot proceed 
since 100 bytes of the systems memory are only avail- 
able to operation A. 

Some programmers attempt to solve this problem 
by preallocating resources. For example, if a program- 
mer knows that they need 100 bytes of memory at the 
start of an operation, another 100 bytes halfway 
through, and 1 00 bytes at the end of the operation, then 
the programmer would allocate 300 bytes of memory 
before beginning the operation. 

Preallocating resources, however, has at least 
three drawbacks. First, in an object oriented environ- 
ment, there may be no way to allocate resources of the 
correct object type in advance. A programmer would 
have to allocate uninitialized instances of a class and 
initialize them later. However, many class implementors 
prohibit the creation of uninitialized instances of their 
class. 

Second, most code is not written with preallocation 
in mind. Therefore, when integrating code that has pre- 
al located resources with existing code that has not pre- 
allocated any resources, there is no way to direct the 



existing code to use the resources that may have been 
preallocated. 

Third, preallocation of resources prohibits intelli- 
gent management by the system. From the perspective 

s of the system, once a resource has been allocated, the 
resource is considered to be in use. Therefore, even if 
some of the resources that have been allocated are not 
actually in use, the system may not manage the allocat- 
ed resources (e.g., temporarily loan some of theallocat- 

10 ed memory to a separate operation). 

SUMMARY OF THE INVENTION 

One embodiment of the invention provides a meth- 
15 od for managing resources in a computer system. Ac- 
cording to one embodiment of the invention, a resource 
manager receives a first request of a first operation. The 
first request identifies a first resource and specifies an 
amount of the first resource needed to execute the first 
20 operation. In response, a resource manager determines 
if the amount of the first resource requested by the first 
request is available to be reserved. In response to the 
amount of the first resource requested by the first re- 
quest being available to be reserved, the resource man- 
25 ager reserves the amount of the first resource requested 
by the first request in advance of allocating the first re- 
source to the first operation. 

BRIEF DESCRIPTION OF THE DRAWINGS 

30 

One embodiment of the invention is illustrated by 
way of example and not limitation in the figures of the 
accompanying drawings, in which like references indi- 
cate similar elements, and in which: 
35 Figure 1 illustrates a computer system capable of 
implementing one embodiment of the invention. 

Figure 2a is a flow diagram describing the steps in 
one embodiment of the invention. 

Figure 2b is a flow diagram describing the steps in 
40 one embodiment of the invention. 

DETAILED DESCRIPTION 

A method is described for reserving resources in 
45 advance of allocating the resources. 

Referring to Figure 1, the computer system upon 
which the one embodiment of the invention can be im- 
plemented is shown as 100. Shown in the memory 104 
of computer system 100 is an operating system 110, 
50 which controls the execution of user application pro- 
grams and provides services such as scheduling, data 
input/output control, and other data management re- 
sponsibilities. 

Included in the operating system is the resource 
55 manager 112, which is a control program responsible 
for the allocation of the computer system's resources. 
The resource manager 1 1 2 could alternatively be stored 
on a computer- readable medium, such as a magnetic 



25 



30 



35 



40 



45 



50 



2 



3 



EP 0 817 041 A2 



4 



disk, accessible via the disk drive unit 120, shown in- 
cluded in the computer system of Figure 1 . The resource 
manager 112 could also be stored on a separate com- 
puter system and accessed over a network connection 
to the computer system 1 00 via the network device 1 22 
also shown included in the computer system 100. 

Also included in the memory 1 04 is the multi-thread- 
ed program 115, which as shown, is presently being ex- 
ecuted. In modem interactive software, a single pro- 
gram can be made up of multiple control flows, com- 
monly referred to as "threads of control" (threads). 
Threads extend the concept of switching between sev- 
eral different running programs (i.e. processes), to 
switching between several different functions executing 
simultaneously within a single program (i.e., multitask- 
ing in a single program). As a result, higher throughput 
and better performance of a single program is achieved 
because one thread can run while another thread is 
sleeping (e.g., fetching data from a disk). 

Multiple threads belonging to one program share 
the same address space, however, each thread does 
have its own program counter (P.C.), register set, and 
stack. As a result, the overhead of switching between 
threads (e.g. saving the state of a few registers, a stack 
pointer, a program counter, etc.) is considerably less 
than the overhead incurred when switching between 
processes (e.g. saving the state of virtual memory 
maps, file descriptors, etc.). 

Computer resources are allocated to each thread in 
order to complete the respective operation associated 
with each thread. The resources allocated could include 
random access memory, network bandwidth, a display, 
a printer, or any other device of the computer system 
that can be allocated to an operation of a running pro- 
gram. 

I n order to obtain the resources needed to complete 
execution of the operation, each thread submits a re- 
quest to the resource manager 112. The resource man- 
ager reads the request to determine the resource re- 
quested and the amount requested. The resource man- 
ager then reads the Resource Status Table 125 (RST) 
to determine if the requested amount of the requested 
resource is available. 

In one embodiment, the RST includes an available 
indicator for each resource, which shows how much of 
that particular resource is available to be reserved (e. 
g., 127). In an alternative embodiment, a reserved indi- 
cator could be used to show the amount of each re- 
source that is presently reserved. 

If the requested amount of the requested resource 
is available, the resource manager reserves the re- 
quested amount of the requested resource (hereinafter 
referred to as the reserved resource). On the other 
hand, if the requested amount of the requested resource 
is not available, the requesting thread may choose not 
to begin its operation. 

When reserving the requested amount of the re- 
quested resource, the resource manager inserts an en- 



try into the Reservation Table 1 30 for the reserved re- 
source. Each entry in the Reservation Table identifies 
the reserved resource, the amount of the resource re- 
served, and the thread that has reserved the resource. 
5 In addition, the resource manager updates the RST to 
reflect the reservation. 

Sometime after the reservation, the reserved re- 
source is allocated to the thread for which it has been 
reserved. By reserving a part of a resource for a request 
10 prior to allocating the resource to the request, the thread 
requesting the resource is certain to have enough of the 
resource to complete its operation. 

When the reserved resource is allocated to the re- 
questing thread, the resource manager updates the In- 
is use Table 145 (IT) to show the reserved resource is 
presently allocated to a thread. When a resource has 
been allocated to a thread it is assumed, from the per- 
spective of the resource manager and the computer sys- 
tem, that the amount of the resource that has been al- 
20 located is in use. 

In alternative embodiments, the invention provides 
a manner of intelligently managing the resources that 
have been reserved. For example, by separating the 
reservation of resources from the allocation of resourc- 
es es, a system may know which resources are currently 
being used and which resources are not being used. As 
a result, resources not in use, but reserved by a thread 
can be temporarily loaned to a higher priority operation. 
Referring to Figure 2, a flow diagram is illustrated 
30 describing the steps of the performing the invention ac- 
cording to one embodiment. In block 202, a thread sub- 
mits a request to the resource manager to obtain the 
resources need to complete execution of an operation 
associated with the thread. In one embodiment, each 
35 request of a thread identifies a resource, the amount re- 
quested, and the priority of the request. In alternative 
embodiments, the requesting thread may also include 
its own priority relative the other threads of the program 
115. 

40 After reading the request of a thread, in decision 
block 204, the resource manager reads the available in- 
dicator (e.g. 127) of the Resource Status Table 125 
(RST) to determine if the requested amount of the re- 
quested resource is available to be reserved. In an al- 
45 ternative embodiment, in decision block 204 the re- 
source manager may also determine whether the 
amount of the requested resource is available to be re- 
served is below a predetermined threshold, wherein the 
amount of the requested resource available to be re- 
50 served would be considered relatively low. 

If the requested amount of the requested resource 
is available, or in the alternative embodiment, exceeds 
the predetermined threshold, in block 206 the resource 
manager reserves the requested amount of the request- 
55 ed resource (hereinafter referred to as the reserved re- 
source). 

More specifically, the resource manager inserts an 
entry 1 38 into the Reservation Table 1 30. In one embod- 
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iment, each entry of the Reservation Table identifies the 
requested resource 131, the amount of the resource that 
is being reserved for the requesting thread 132, the 
thread that has requested the resource 1 33, the priority 
of the request as normal or non-essential 1 34, and pos- 
sibly indicate the priority of the requesting thread 135. 
In alternative embodiments, the entries of the RST may 
vary within the scope of the invention, so long as they 
indicate which resources have been allocated. Moreo- 
ver, the priority levels other than normal or non-essential 
can be assigned to the request of each requesting 
thread without deviating from the scope of the invention. 

In block 208, the resource manager updates the 
available indicator 127 of the RST to show that the re- 
served resource is not available to be reserved. 

In block 210, sometime after the resource manager 
has reserved the requested amount of the requested re- 
source, the reserved resource is dynamically allocated 
to the respective thread for which it has been reserved. 
The dynamic allocation is defined as allocating portions 
of the reserved resource to the requesting thread as the 
reserved resource is needed by the requesting thread. 

In response to part of the reserved resource being 
dynamically allocated to the requesting thread, in block 
212, the resource manager updates the In-use Table 
145 to show the amount of the reserved resource that 
is presently allocated to the thread which has requested 
the resource. In one embodiment, each entry of the In- 
use Table may indicate the resource 146, the amount 
presently allocated 147, and thread to which the re- 
source has been allocated 148. 

For example, if a threadl has reserved 100 kilo- 
bytes (K) of memory, but initially is only allocated 25K, 
the entry for threadl 's In-Use table will indicate only 25K 
has been allocated to threadl. Moreover, if threadl is 
initially allocated 1 00K of memory and part way through 
its execution, threadl is finished with 50K of the memory, 
the resource manager may update threadl's entry to 
show that only 50K of memory is now allocated to 
threadl. 

In one embodiment, if the resource manager deter- 
mines in decision block 204 that the requested amount 
of the requested resource is not available, or in the al- 
ternative embodiment, determines that the amount 
available is below the predetermined threshold, the re- 
source manager attempts to suspend a prior request. In 
an alternative embodiment, when the requested re- 
source is below the predetermined level, the resource 
manager may be programmed to reject the request if 
the request is non-essential or the priority of the thread 
requesting the resource is below a predetermined level 
of priority. 

When attempting to suspend a prior request, in 
block 214, the resource manager reads the Reservation 
table to find a prior request of a separate thread that has 
already reserved enough of the requested resource to 
satisfy the present request which has been unable to 
reserve part of the requested resource. In an alternative 



embodiment, the resource manager may attempt to sus- 
pend a group of prior requests, which together have re- 
served enough of the requested resource to satisfy the 
present request. 
5 Once the resource manager has found a prior re- 
quest which has reserved enough of the requested re- 
source to satisfy the present request, in block 216, the 
resource manager reads the In-use Table to determine 
how much of the requested resource has been allocated 
to the prior request. If the requested resource is unallo- 
cated to the prior request, or if enough of the requested 
resource to satisfy the present request is unallocated to 
the prior request, in decision block 218, the resource 
manager performs a logical comparison between the 
prior request and the present request. Otherwise, in 
block 217, the resource manager rejects the present re- 
quest. 

The logical comparison performed by the resource 
manager in block 218 is predetermined. The logical 
comparison, for example, may compare the priority of 
the present request with the priority of the prior request, 
and/or the priority of the present requesting thread to 
the priority of the prior requesting thread. 

If the prior request exceeds the present request in 
the comparison, in block 220, the resource manager will 
reject the present request or attempt to suspend another 
prior request. On the other hand, if the present request 
exceeds the prior request in the logical comparison, in 
block 222 the resource manager will temporarily sus- 
pend the prior request and insert an entry in the reser- 
vation table for the present request. Suspending the pri- 
or request is transparent to a user of the computer sys- 
tem. 

In one embodiment, the entry of the present request 
in the Reservation Table will include a pointer 1 37 to the 
suspended prior request. As a result, when the present 
request is finished with the requested resource, the re- 
source manager will read the pointer to determine which 
prior request to unsuspend. Moreover, the entry of the 
suspended request in the Reservation Table, may in- 
clude a field 136 that is set to indicate the respective 
request is presently suspended. 

Consider the example shown in the memory of Fig- 
ure 1. The third thread 138 submitted a request to the 
resource manager to obtain 150K of memory. The re- 
source managers read the RST and determined that all 
of memory has been reserved. The resource manager 
then read the reservation table and saw that the second 
thread 139 has reserved 150K of memory, enough to 
satisfy the request of the third thread 1 39. 

The resource manager then compared the priority 
of the third thread's request for memory (normal) with 
the priority of the second thread's request for memory 
(non-essential). The resource manager may also have 
compared the priority of the third request (2nd) to the 
priority of the second request (9th). 

After, the resource manager had determined the 
third thread's request exceeded the second thread's re- 



15 



20 



25 



30 



35 



40 



45 



50 



4 



7 



EP 0 817 041 A2 



8 



quest, the resource manager then read the In-use table 
and determined that no memory had been allocated to 
the second thread. As a result, the resource manager 
suspended the request of the second thread 139 and 
inserted an entry into the Reservation Table for the re- 
quest of the third thread 1 38. 

The entry in the Reservation Table for the request 
of the third thread 139 includes a pointer to the request 
of the second thread. As a result, after the third thread 
is finished with the memory, the resource manager will 
read the pointer of the request for the third thread and 
unsuspend the second thread's request for memory, as 
is shown in block 224. 

In the foregoing specification the invention has 
been described with reference to specific exemplary 
embodiments thereof. It will, however, be evident that 
various modifications and changes may be made there- 
to without departing from the broader spirit and scope 
of the invention. For instance, where it has been shown 
that the resource manager, including the RST, the In- 
use Table, and the Reservation Table are in memory 
1 04, these items may also be stored on a magnetic or 
optical disk and accessed via the disk drive 1 20. 

The specification and drawings are, accordingly, to 
be regarded in an illustrative rather than restrictive 
sense. Moreover, the following claims indicate the 
scope of the invention, and all variations which come 
within the meaning and range of equivalency of the 
claims are to be embraced within their scope. 



Claims 

1 . A computer-implemented method for managing re- 
sources in a computer system comprising the steps 

of: 

a resource manager receiving a first request of 
a first operation, said first request identifies a 
first resource and specifies an amount of the 
first resource needed to execute the first oper- 
ation; 

the resource manager determining if the 
amount of the first resource specified by the 
first request, is available to be reserved; and 
in response to the amount of the first resource 
specified in the first request being available to 
be reserved, the resource manager reserving 
the amount of the first resource specified in the 
first request in advance of allocating the first re- 
source to the first operation. 



3. The computer-implemented method of claim 2, fur- 
ther including the step of: 

in response to the amount of the first resource 
being unavailable to be reserved, the resource 
5 manager rejecting the first request. 

4. The computer-implemented method of claim 2, 
wherein the resource manager includes a resource 
status table, said resource status table indicates an 

10 amount of the first resource available to be reserved 
by a thread; 

said resource manager includes a reservation 
table, said reservation table stores resource 

15 reservations for the set of threads, wherein 

each entry in the reservation table identifies a 
resource, an amount of the resource reserved, 
a thread for which the resource has been re- 
served, and a priority of the request of the 

20 thread for which the resource has been re- 

served, and 

said resource manager further includes an in- 
use table, said in-use table indicates an amount 
of a resource having been allocated to a th read. 

25 

5. The computer-implemented method of claim 4, 
wherein the step of determining if the amount of the 
first resource specified by the first request is avail- 
able, further includes reading the resource status 

30 table to determine if the amount of the first resource 
specified by the first request, is available to be re- 
served. 

6. The computer-implemented method of claim 5, 
35 wherein the step of the resource manager reserving 

further includes the steps of: 

inserting an entry into the reservation table; and 
updating the resource status table to indicate 
40 the amount of the first resource specified in the 

first request is unavailable to be reserved. 

7. The computer-implemented method of claim 6, fur- 
ther including the step of: 



45 dynamically allocating at least a part of the 

first resource to the first thread, wherein the re- 
source manager updates the in-use table to indicate 
the part of the first resource presently allocated to 
the first thread. 

50 

8. The computer-implemented method of claim 7, fur- 
ther including the steps of: 

in response to the first thread being finished 
55 with the first resource, updating the resource 

status table to indicate an amount of the first 
resource allocated to the first thread is availa- 
ble to be reserved, 



2. The computer-implemented method of claim 1, 
wherein the first operation is a first thread, said first 
thread is one of a set of threads belonging to one 
program, said set of threads sharing one address 
space, and each thread of said set of threads is al- 
located an individual program counter. 
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and updating the in-use table to indicate the 
amount of the first resource allocated to the first 
thread is available to be allocated. 



ond thread exceeding the first request of the first 
thread in the logical comparison, the resource man- 
ager rejecting the first request of the first thread. 



9. The computer-implemented method of claim 8, 
wherein the step of the resource manager determin- 
ing if the amount of the first resource specified by 
the first request is available further includes the 
steps of: 

the resource manager reading the resource 
status table to determine if an amount of the first 
resource available to be reserved is below a prede- 
termined threshold. 



s 14. The computer-implemented method of the claim 13, 
wherein the resource manager is part of an operat- 
ing system of a limited resource computer system. 

15. A computer-readable medium having stored there- 
to on a plurality of sequences of instructions, said se- 
quences of instructions including instructions 
which, when executed by a processor, cause said 
processor to perform the steps of: 



10. The computer-implemented method of claim 9, fur- 
ther including the step of: 

in response to the amount of the first resource 
available to be reserved being below the predeter- 
mined threshold and the priority of the first request 
being nonessential or a priority of first thread being 
below a predetermined priority, the resource man- 
ager rejecting the first request. 

11. The computer-implemented method of claim 10, 
wherein the step of the resource manager determin- 
ing if the amount of the first resource specified by 
the first request is available to be reserved, further 
includes the steps of: 

in response to the amount of the first resource 
specified by the first request being unavailable 
or the amount of the first resource available to 
be reserved being below the predetermined 
threshold, the resource manager performing a 
predetermined logical comparison of the first 
request of the first thread to a second request 
of a second thread, said resource manager 
having reserved at least a part of the first re- 
source for the second request in advance of al- 
locating the first resource to the second thread; 
and 

in response to the first request of the first thread 
exceeding the second request of the second 
thread in the logical comparison, the resource 
manager temporarily suspending the second 
request of the second thread and reserving at 
least a part of the first resource for the first re- 
quest of the first thread. 

1 2. The computer-implemented method of claim 1 1 , fur- 
ther comprising the steps of: 

unsuspending the second request of the sec- 
ond thread after the first thread is finished with the 
first resource. 

13. The computer-implemented method of claim 12, 
further includes the step of: 

in response to the second request of the sec- 



15 receiving a first request of a first operation, said 

first request identifies a first resource and spec- 
ifies an amount of the first resource needed to 
execute the first operation; 
determining if the amount of the first resource 
20 specified by the first request, is available to be 

reserved; and 

in response to the amount of the first resource 
specified in the first request being available to 
be reserved, reserving the amount of the first 
25 resource specified in the first request in ad- 

vance of allocating the first resource to the first 
operation. 

16. The computer-readable medium of claim 15, where- 
30 jn the first operation is a first thread, said first thread 

is one of a set of threads belonging to one program, 
said set of threads sharing one address space, and 
each thread of said set of threads is allocated an 
individual program counter. 

35 

17. The computer-readable medium of claim 16, further 
having stored thereon additional instructions which, 
when executed by a processor, cause said proces- 
sor to perform the step of: 

40 in response to the amount of the first resource 

being unavailable to be reserved, rejecting the first 
request. 

18. The computer-readable medium of claim 16, further 
45 having stored thereon a resource manager, the re- 
source manager includes a resource status table, 
said resource status table indicates an amount of 
the first resource available to be reserved by a 
thread; 

so 

said resource manager includes a reservation 
table, said reservation table stores resource 
reservations for the set of threads, wherein 
each entry in the reservation table identifies a 
55 resource, an amount of the resource reserved, 

a thread for which the resource has been re- 
served, and a priority of the request of the 
thread for which the resource has been re- 



50 



20 



6 



11 



EP 0 817 041 A2 



12 



served, and 

said resource manager further includes an in- 
use table, said in-use table indicates an amount 
of a resource having been allocated to a thread. 

1 9. The computer-readable medium of claim 1 8, where- 
in the step of determining if the amount of the first 
resource specified by the first request is available, 
further includes reading the resource status table to 
determine if the amount of the first resource speci- 
fied by the first request, is available to be reserved. 

20. The computer-readable medium of claim 1 9, where- 
in the step of the resource manager reserving fur- 
ther includes the steps of: 

inserting an entry into the reservation table; and 
updating the resource status table to indicate 
the amount of the first resource specified in the 
first request is unavailable to be reserved. 

21 . The computer-readable medium of claim 20, further 
having stored thereon additional instructions which, 
when executed by a processor, cause said proces- 
sor to perform the step of: the step of: 

dynamically allocating at least a part of the 
first resource to the first thread, wherein the re- 
source manager updates the in-use table to indicate 
the part of the first resource presently allocated to 
the first thread. 

22. The computer-readable medium of claim 21 , further 
having stored thereon additional instructions which, 
when executed by a processor, cause said proces- 
sor to perform the step of: 

in response to the first thread being finished 
with the first resource, updating the resource 
status table to indicate an amount of the first 
resource allocated to the first thread is availa- 
ble to be reserved, 

and updating the in-use table to indicate the 
amount of the first resource allocated to the first 
thread is available to be allocated. 

23. The computer-readable medium of claim 22, where- 
in the step of determining if the amount of the first 
resource specified by the first request is available 
further includes the steps of: 

the resource manager reading the resource 
status table to determine if an amount of the first 
resource available to be reserved is below a prede- 
termined threshold. 

24. The computer-readable medium of claim 23, further 
having stored thereon additional instructions which, 
when executed by a processor, cause said proces- 
sor to perform the step of: 



in response to the amount of the first resource 
available to be reserved being below the predeter- 
mined threshold and the priority of the first request 
being nonessential or a priority of first thread being 
5 below a predetermined priority, the resource man- 
ager rejecting the first request. 

25. The computer- readable medium of claim 23, where- 
in the step of determining if the amount of the first 

10 resource specified by the first request is available 
to be reserved, further includes the steps of: 

in response to the amount of the first resource 
specified by the first request being unavailable 

f5 or the amount of the first resource available to 

be reserved being below the predetermined 
threshold, the resource manager performing a 
predetermined logical comparison of the first 
request of the first thread to a second request 

20 of a second thread, said resource manager 

having reserved at least a part of the first re- 
source for the second request in advance of al- 
locating the first resource to the second thread; 
and 

25 in response to the first request of the first thread 

exceeding the second request of the second 
thread in the logical comparison, the resource 
manager temporarily suspending the second 
request of the second thread and reserving at 
30 least a part of the first resource for the first re- 

quest of the first thread. 

26. The computer-readable medium of claim 25, further 
having stored thereon additional instructions which, 

35 when executed by a processor, cause said proces- 
sor to perform the step of: 

unsuspending the second request of the sec- 
ond thread after the first thread is finished with the 
first resource. 

40 

27. The computer-readable medium of claim 26, further 
having stored thereon additional instructions which, 
when executed by a processor, cause said proces- 
sor to perform the step of: 

45 jn response to the second request of the sec- 

ond thread exceeding the first request of the first 
thread in the logical comparison, the resource man- 
ager rejecting the first request of the first thread. 

50 28. The computer-readable medium of the claim 27, 
wherein the resource manager is part of an operat- 
ing system of a limited resource computer system. 

29. A computer system configured to manage resourc- 
es es, the computer system comprising of: 

a resource manager configured to receive a 
first request of a first operation, said first re- 
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quest identifies a first resource and specifies an 
amount of the first resource needed to execute 
the first operation; 

the resource manager further configured to de- 
termine if the amount of the first resource spec- 
ified by the first request, is available to be re- 
served; and 

the resource manager further configured to re- 
serve, in response to the amount of the first re- 
source specified in the first request being avail- 
able to be reserved, the amount of the first re- 
source specified in the first request in advance 
of allocating the first resource to the first oper- 
ation. 

30. The computer system of claim 29, wherein the first 
operation is a first thread, said first thread is one of 
a set of threads belonging to one program, said set 
of threads sharing one address space, and each 
thread of said set of threads is allocated an individ- 
ual program counter. 

31. The computer system of claim 30, wherein the re- 
source manager is further configured to reject the 
first request in response to the amount of the first 
resource being unavailable to be reserved. 

32. The computer system of claim 30, wherein the re- 
source manager includes a resource status table, 
said resource status table indicates an amount of 
the first resource available to be reserved by a 
thread; 

said resource manager includes a reservation 
table, said reservation table stores resource 
reservations for the set of threads, wherein 
each entry in the reservation table identifies a 
resource, an amount of the resource reserved, 
a thread for which the resource has been re- 
served, and a priority of the request of the 
thread for which the resource has been re- 
served, and 

said resource manager further includes an in- 
use table, said in-use table indicates an amount 
of a resource having been allocated to a thread. 

33. The computer system of claim 32, wherein the re- 
source manager is configured to read the resource 
status table to determine if the amount of the first 
resource specified by the first request is available 
to be reserved. 

34. The computer system of claim 33, wherein resource 
manager is configured to insert an entry into the res- 
ervation table and update the resource status table 
to indicate the amount of the first resource specified 
in the first request is unavailable to be reserved, in 
order to reserve the amount of the first resource 



specified in the first request. 

35. The computer system of claim 34, wherein the re- 
source manager is configured to dynamically allo- 
s cate at least a part of the first resource to the first 
thread and update the in-use table to indicate the 
part of the first resource presently allocated to the 
first thread. 

10 36. The computer system of claim 35, wherein the re- 
source manager is configured to update, in re- 
sponse to the first thread being finished with the first 
resource, the resource status table to indicate an 
amount of the first resource allocated to the first 

?5 thread is available to be reserved, and update the 
in-use table to indicate the amount of the first re- 
source allocated to the first thread is available to be 
allocated. 

20 37. The computer system of claim 36, wherein the re- 
source manager is configured to read the resource 
status table to determine if an amount of the first 
resource available to be reserved is below a prede- 
termined threshold. 

25 

38. The computer system of claim 37, the resource 
manager is configured to reject the first request in 
response to the amount of the first resource avail- 
able to be reserved being below the predetermined 

30 threshold and the priority of the first request being 
nonessential or a priority of first thread being below 
a predetermined priority. 

39. The computer system of claim 37, wherein the re- 
35 source manager is configured to perform, in re- 
sponse to the amount of the first resource specified 
by the first request being unavailable or the amount 
of the first resource available to be reserved being 
below the predetermined threshold, a predeter- 

40 mined logical comparison of the first request of the 
first thread to a second request of a second thread, 
said resource manager having reserved at least a 
part of the first resource for the second request in 
advance of allocating the first resource to the sec- 
45 ond thread; and 

the resource manager further configured to 
temporarily suspend, in response to the first request 
of the first thread exceeding the second request of 
the second thread in the logical comparison, the 
so second request of the second thread and reserve 
at least a part of the first resource for the first re- 
quest of the first thread. 

40. The computer system of claim 39, wherein the re- 
55 source manager configured to unsuspend the sec- 
ond request of the second thread after the first 
thread is finished with the first resource. 
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41. The computer system of claim 40, wherein the re- 
source manager is configured to reject the first re- 
quest in response to the second request of the sec- 
ond thread exceeding the first request of the first 
thread in the logical comparison. 

42. The computer system of the claim 41 , wherein the 
resource manager is part of an operating system of 
a limited resource computer system. 
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